在現代資料棧的設計中， ELT 逐漸取代 ETL 成為主流，因此複雜的資料轉換多在資料倉儲中發生，如何在資料管線 (Data Pipeline) 的各個階段中針對不同的需求採取不同的資料建模，能讓資料管線的開發更具彈性。
在 ELT 的架構下，多數資料會不經任何轉換就寫入資料倉儲內，所以原始資料層的資料模型通常通常就是 OLTP 中的資料模型。但比起 OLTP 的系統， 資料倉儲多了需要儲存歷史變更紀錄的的需求，因此原始資料層通常也包含以下兩種資料模型。
| company_id | company_name | city | created_at | updated_at |
|---|---|---|---|---|
| 1 | McBurger | 台北 | 2024-01-03 09:23:24 | 2024-01-03 09:23:24 |
McBurger 在七月時搬到台中，負責的窗口進行公司資料維護時，在 OLAP 的系統中則只會保留：
| company_id | company_name | city | created_at | updated_at |
|---|---|---|---|---|
| 1 | McBurger | 台中 | 2024-01-03 09:23:24 | 2024-07-03 09:23:24 |
而在資料倉儲的原始資料層，則會以下列形式保存：
| company_id | company_name | city | created_at | valid_from | valid_to | loaded_at |
|---|---|---|---|---|---|---|
| 1 | McBurger | 台北 | 2024-01-03 09:23:24 | 2024-01-03 09:23:24 | 2024-07-03 09:23:24 | 2024-01-04 00:12:02 |
| 1 | McBurger | 台北 | 2024-01-03 09:23:24 | 2024-07-03 09:23:24 | 2024-07-04 00:12:05 |
| company_Id | company_name | city | created_at | updated_at | loaded_at |
|---|---|---|---|---|---|
| 1 | McBurger | 台北 | 2024-01-03 09:23:24 | 2024-01-03 09:23:24 | 2024-01-03 09:23:24 |
| 1 | McBurger | 台北 | 2024-01-03 09:23:24 | 2024-07-03 09:23:24 | 2024-07-03 09:23:25 |
Snapshot 與 CDC 的差別在於，Snapshot 在做資料更新時，通常是以 Batch 的方式，CDC 則是以 near real-time / real-time 的方式更新。兩者通常也會加上 is_current_record 方便判斷哪方便判斷哪一筆是最新的資料。
當我們用資料建模談資料處理層時，其實比較偏向用 dbt 的 data modeling 概念 （而不是 schema 設計）在談資料建模，因此詳情可以參考 dbt 建議的專案架構 或是 Medallion Architecture，中文資源可以參考這屆鐵人賽團友的文章 。
（不過我跟這位團友對於 data mart 的概念不太一樣，我的系列文還是以我自己所希望傳遞的概念為主
）
這類型的資料建模通常用在資料源複雜而且相對容易變動的時候，目的是更快速精準的捕捉每次資料源的變動。 Data Vault 的設計通常是放在 staging （整理欄位名稱以及欄位型態） 後面。資料源的資料建模如果是屬於 CDC 型態，其實就很適合。
我自己在前公司曾經偷偷玩過 data vault。當時使用的情境時，資料源的 OLTP 是採用 NoSQL，因此許多欄位都集中在同一張表中，但我們只對特定幾個欄位的變動狀況感興趣，為了方便辨認特定欄位的改動狀況，決定實驗看看這類型的資料建模有沒有辦法解決問題，時做的過程很有趣，但因為實在沒有人力維護，最後只好作罷。
我想，在資料源資料建模有處理好，而且有不少 dbt package 可以幫忙做轉換的情況下，試做起來不會太困難，但維護起來就不曉得了 :P。
Data Vault 2.0 的 中文資源則可以參考上一屆團友的系列文。
在這一層的設計主要是 Star Schema 以及 Snowflake Schema ，這兩者通常可以並存，其目的是為了更方便進行商業分析以及報表 / 儀表板的製作。值得一提的是 star schema 以及 snowflake schema 是可以彼此相容的，通常都是以混合兩者為主，下一篇將會對這兩種 schema 進行詳細的介紹。之後的系列文也會以從資料源實做出 Data Mart 為目標進行教學。
Report Level 則是接在 Data Mart 後面，型態通常都是 One Big Table (OBT)，目的是為了生成報表 / 分析。也就是說他通常是 End-User 最後看到的產物。每提出一次需求就會有一個 OBT 的產生，OBT 與 OBT 彼此之間也相當獨立。
從目的來說， Data Mart 是依賴於相對不容易變動的商業模式本身， OBT 則是依賴於容易飄忽不定的 ad-hoc / dashboard request。這也是為什麼我在上一篇提到 （我個人也不喜歡）不應將一張大表定義為資料建模的原因。
實做時，OBT 就是將 Data Mart 的 Dimension 與 Fact 結合起來，再根據需要的顆粒度進行 Summarize
資料工程相對於軟體工程，更重視對於歷史狀態的處理以及管理。因此該如何透過正確的資料建模以及轉換邏輯的模組化讓資料管線更容易開發以及維護，每一次實作時，都會根據資料源狀況以及資料團隊本身的資源，而採取不同的作法。
同時，資料流水線內的資料建模，也是個相對新興的領域，也有人在研究如何透過演算法將 data vault 有效率且系統性地轉換成 data mart 等等。
但在資料市集的設計中， Snowflake Schema 以及 Star Schema，不只是經典，更是近乎不敗的資料建模方法 （尤其是對商業智慧來說）。因此接下來將會介紹如何設計出一個具有彈性，能支援多種報表生成的資料市集。
iThome鐵人賽
看影片追技術